The
previous design patterns provide the necessary basis to build systems
with SQL Azure. Some of these patterns can be used as is, but you're
very likely to combine patterns to deliver improved solutions. This
section describes some useful combinations.
1. Transparent Branching + RWS
Figure 1
shows the transparent branching and the read-write shard patterns
combined. This pattern can be used to offload into the cloud storage of
historical data that an existing Enterprise Resource Planning (ERP)
application generates. In this example, the shard provides a way to
ensure high throughput by using asynchronous round-robin calls into SQL
Azure databases.
This pattern offers the following advantages:
Transparent data transfer.
In this case, the transparent branching pattern copies an existing
application's data into cloud databases without changing a single line
of code in the existing application.
High performance. To ensure high performance and throughput, the round-robin shard pattern is used along with asynchronous calls into the cloud.
Scalable.
When using a shard, it's very simple to expand it by adding a new SQL
Azure database into the cloud. If implemented correctly, the shard
automatically detects the new database and storage capacity, and
throughput automatically increases.
2. Cascading Aggregation
In cascading aggregation (see Figure 2),
the aggregation pattern is applied serially to generate a summary
database. The mechanism to copy (or move) data from one SQL Azure
database to another must be accomplished using a high-level process,
such as a worker process in Windows Azure.
For example, this pattern can
be used to collect information from multiple SQL Azure databases into a
single one used by a third party to monitor overall performance. A
Windows Azure worker process can run a performance view provided by SQL
Azure and store the data into another database. Although the SQL Azure
databases being monitored for performance may have a totally different
schema, the output of SQL Azure's performance data management view
(DMV) is consistent. For example, the monitoring service can call sys.dm_exec_connections
to monitor connection activity in various SQL Azure databases every 5
minutes and store the result in a separate SQL Azure database.